In Third Generation Partnership Project (3GPP) standards Release 5 and 6, a WTRU generates an RLC layer status report upon a serving HS-DSCH cell change in order to recover data buffered in a source Node-B at the moment of handover.
For inter Node-B, and some intra Node-B, serving HS-DSCH cell changes, the SRNC signals a medium access control-high speed (MAC-hs) layer reset to the WTRU, which resets any hybrid automatic repeat request (HARQ) processes upon reception, and forwards data in downlink (DL) reordering queues to the RLC layer. Once this data has been processed, a serving cell change status report is transmitted from the WTRU to the SRNC. The process described above will generally be referred to herein as a “serving cell change” procedure.
In an intelligent RLC operation, the SRNC receives the serving cell change status report and determines which packet data unit (PDU) buffered at the source Node-B should be retransmitted. This intelligent implementation requires the SRNC RLC entity to distinguish between old status reports that are potentially delayed in uplink (UL) reordering queues, and the status reports that are sent as a result of the serving cell change procedure. The intelligent RLC operation further requires that the SRNC RLC retransmits all outstanding transmitted PDUs, not just the PDUs that have been explicitly negatively acknowledged (NACKed) in the serving cell change status report. If the SRNC does not provide intelligent implementation logic, recovery of the source Node-B's buffered data may be further delayed.
In a non-intelligent RLC operation, retransmissions only result when PDUs are marked as unsuccessfully received (NACKed) in serving cell change status reports. Such serving cell change status reports identify successfully and unsuccessfully received (i.e., missing) PDUs up to the last correctly received PDU sequence number. When a serving cell change status report is received as a result of a serving HS-DSCH cell change, smart implementations will retransmit all previously transmitted data which is not indicated as having been successfully received.
FIG. 1 is a block diagram of a conventional wireless communication system 100 including an SRNC 105 and a WTRU 110. The WTRU 100 includes a processor 115, a transmitter 120, a receiver 125, a status prohibit timer 130 and an antenna 135. The SRNC 105 includes an antenna 140, a transmitter 145, a receiver 150 and a processor 155. The SRNC 105 controls handover between a source Node-B 142 and a target Node-B 144.
FIG. 2A shows an example of a serving cell change procedure implemented by the conventional wireless communication system 100 of FIG. 1, whereby five RLC PDUs are transmitted by the SRNC 105 and only one of the transmitted PDUs is successfully received by the WTRU 110. As shown in FIG. 2A, if PDUs 1, 2, 3, 4 and 5 are transmitted by the SRNC 105 via its antenna 140, and the WTRU 110 only successfully receives PDU 3 in advance of a serving cell change via its antenna 135, the WTRU 110 sends a serving cell change status report 155A to the SRNC 105 via the antenna 135 and the status prohibit timer 130 is activated. As referred to hereafter, the terminology “normal status report” refers to a status report that indicates the status of data, (i.e., PDUs), that was successfully received and/or not successfully received after a serving cell change status report is sent.
FIGS. 2B and 2C shows how a non-intelligent radio network controller (RNC) RLC operation may be implemented by the conventional wireless communication system 100 of FIG. 1 for the example of FIG. 2A.
As shown in FIG. 2B, only PDUs 1 and 2 are retransmitted by the SRNC 105 via the antenna 140 as a result of the SRNC 105 receiving the serving cell change status report 155A via the antenna 140. Then, the SRNC 105 resumes with the regular transmission, starting with PDU 6. However, after PDUs 1 and 2 are retransmitted by the SRNC 105, and the PDU 6 is transmitted by the SRNC 105 and received by the WTRU 110, a normal status report 155B is sent by the WTRU 110 that explicitly signals the unsuccessful delivery of PDUs 4 and 5, (as well as the successful delivery of PDU 6). However, this does not occur until after the status prohibit timer 130 expires, thus causing a delay in recovering the PDUs 4 and 5.
FIG. 2C shows the SRNC 105 retransmitting PDUs 4 and 5 after the SRNC 105 receives the normal status report 155B from the WTRU 110 during the non-intelligent radio network controller (RNC) RLC operation.
FIG. 2D shows how an intelligent RNC RLC operation may be implemented by the conventional wireless communication system 100 of FIG. 1 for the example of FIG. 2A. As shown in FIG. 2D, the SRNC 105 retransmits, via the antenna 140, all of the PDUs that the serving cell change status report 155A of FIG. 2A did not indicate as having been successfully received. Accordingly, PDUs 1, 2, 4 and 5 are retransmitted in the target Node-B 144. Thus, data lost in the source Node-B 142 is fully recovered.
The status prohibit timer 130 in the WTRU 110 is configured by radio resource control (RRC) signaling. Unfortunately, the status prohibit timer 130 is often configured to reduce the frequency of repetitive normal status reports, which further delays the normal status report triggered by the reception of PDU 6 and the retransmissions of PDUs 4 and 5.
One solution to avoid the additional delay in sending normal status reports caused by the status prohibit timer 130 in the WTRU 110, is for the WTRU 110 to wait for the first PDU to be received, (which increases the receive sequence), before generating a normal status report. However, this solution results in eliminating the fast recovery of source Node-B buffered data offered by the intelligent RNC RLC operation.
Additionally, it could be argued further that just removing the normal status report criteria would provide a similar result as the proposed solution for the case described. If PDU 6 is received out-of-sequence, the normal status report will be generated. Otherwise, there is no data to recover and, in this case, the unnecessary generation of a normal status report is avoided.
The case where the last PDU is transmitted in the source Node-B 142 also needs to be considered. For example, take the case described above where PDU 5 is the last PDU to be transmitted. In this case, without PDU 6 causing out-of-sequence triggering of the normal status report, the intelligent RLC implementation is the only way to achieve fast recovery.
A solution that allows for the intelligent RNC RLC operation benefits, without negatively effecting non-intelligent RNC RLC operations, is needed. The generation of a status report upon a serving cell change should be maintained for fast data recovery by intelligent RNC RLC operations, while recovery by non-intelligent RNC RLC operations should not be further delayed.